Thanks for the PR, but after re-reading the code it seems that the existing implementation is correct, returning the allocated size chosen by the user on start.

For example, if you do EEPROM.begin(512) then EEPROM.length() returns 512, the total number of bytes you can write to it. You can't write to EEPROM[512], that's not allocated or legal and will fail.

Thanks for circling back to this... But I'm not seeing anything like that. Have you looked here? .begin() should return the starting address of the EEPROM and length should work as discussed.

    //STL and C++11 iteration capability.
    EEPtr begin()                        { return 0x00; }
    EEPtr end()                          { return length(); } //Standards requires this to be the item after the last valid entry. The returned pointer is invalid.
    uint16_t length()                    { return E2END + 1; }
    

Not sure what EEPtr is, but here you need to pass in a size in begin():

EEPtr doesn't make sense here because we're not real EEPROM nor is there a real physical address associated w/the data until it's persisted by a commit (which might not be needed on non-emulated since they can write single bytes....here we can only write 256byte chunks at a time and need to erase an entire 4K before doing so).

I see that is how your version works--which is handy--but it breaks Arduino compatibility. And that's fine except for the name "arduino-pico" implies compatibility. Did you check the link to the actual Arduino library I sent? I linked it directly to the begin method which doesn't take any params in so if I use it the way your version is written, it will not work on an Arduino. Given that your version of begin has the correct value, wouldn't it make more sense to have it be in the constructor? That would allow you to have your cake and eat it too (happy to change the PR if that's what you're after).

Sorry for the trouble.

Yes, you will need to pass in the needed size so you'll need to ever so slightly modify the code. #ifdef can be used if you really need to build the exact same source on 8-bit AVR and 32-bit Pico (and ESP32 and ESP8266).

Even if we add a default parameter to the begin method like void begin(size_t size = 4096);, you would still need to call the commit method or lose everything on power cycle/reboot. That's just physical because you don't have a byte-writable EEPROM onboard.

That said, in most cases EEPROM is the wrong way to do what you want to do. Look at File and LittleFS which are much more powerful, do wear leveling, and aren't limited to some artificial limit.

To save us both some time, to be clear, you don't care about Arduino compatibility despite our brief exchange yesterday? As it stands, this behaves like an ESP32 not an Arduino which means there are breaking changes between the two.

Physically there is no EEPROM on board, so we give it a best effort wrapper for really old AVR code. We do support the templated writes which seems to have covered most legacy use cases.

I think you're trying to add in the iterator (but I don't think they actually subclassed std::iterator in the AVR core so I'm not sure many things can use it)? I suppose if it doesn't break existing code and has a test/sample it'd be OK, but I really don't think it's worth anyone's time in 2024.

FWIW, there's no EEPROM library, at all, on the official Arduino Nano RP2040 Connect MBED core (looking at the installed dirs).

Physically, you cannot write to flash the same way as EEPROM, so this and the ESP cores add a commit() method to actually persist data. It's still not the same a EEPROM as in the EEPROM case physically you could probably expect to lose 1 byte worth of data...with flash you can lose the entire 4K if the powerfail happens after the erase and before rewrite. If you erased and rewrote after every byte change that would have a danger window around every byte and also make it much more likely to wear out the flash sector.

That's where something like LittleFS comes in, with wear leveling and power fail safety and a lot more capabilities.

Yeah, we've been over all of this. I am just trying to ensure consistent behavior. I appreciate the technical issues you have outlined and the thorough explanations.

In my use case (and for the sake of Arduino compatibility), it makes sense. From my perspective, leveraging another tool that is massively overbuilt for the storing of 17-62 bytes that will likely not be rewritten more than monthly if ever on a device with an expected lifespan of ten years seems silly.

I'll work on putting something together. Thank you for your time and perspective.